This invention relates generally to systems for managing memory usage in electronic computing systems utilizing object-oriented technology. More particularly, the present invention is a computer programming system which allows development of computer memory pointer information, providing enhanced memory management functionality. This information may, for example, be utilized to automatically determine when memory links may be broken, freeing up computer memory.
Many computer languages contain features that assist in memory management for modern digital computers, especially in object-oriented environments, such as with C++Tm programs. Typically in an object-oriented environment, any time a given object is no longer referenced anywhere in a program, it is considered xe2x80x98garbagexe2x80x99 and is xe2x80x98cleaned-upxe2x80x99 at the first convenient opportunity. However, the program must be coded to know how and when to break all references to a given object that is to be deleted.
One complication to such memory management occurs when the primary uses of an object cease, although less significant references to the object are still present. Such a situation can prevent cleanup of the program objects which would normally be considered garbage. In effect, in such a situation there are two different basic classes of relationships. First, there are references which claim xe2x80x98ownershipxe2x80x99 of the objects to which they point. That is, while the reference exists to the object, the object should not be garbage collected. Secondly, there are references which do not claim xe2x80x98ownershipxe2x80x99 of any kind. The objects to which they refer may be eliminated at any point, although the referring objects may need to be informed of the changed situation. Further, if the referenced objects are garbage-collected, the references (pointers) to the eliminated objects must be xe2x80x98brokenxe2x80x99 (Led out) to prevent dangling pointer problems.
An approach to addressing the cleanup of such objects has been to use a two-tier pointer scheme in which xe2x80x9cstrongxe2x80x9d pointers and xe2x80x9cweakxe2x80x9d pointers are used to reference to objects. Generally, such memory management systems are allowed to consider objects to be garbage which do not have any strong references, regardless whether weak references are present. Such systems are identified in U.S. Pat. No. 5,560,003, assigned to Iowa State University Research Foundation Inc. (the xe2x80x9c""003 patentxe2x80x9d) and U.S. Pat. No. 5,765,174, assigned to Sun Microsystems, Inc. (the xe2x80x9c""174 patentxe2x80x9d), each of which is incorporated herein by reference.
Distinguishing between such weak and strong (or non-owning and owning) relationships, clearly assists in memory management by allowing garbage collection of weak referenced objects. However, in complex applications that distinction alone can be inadequate because the classical implementation of a weak pointer is that it is simply a pointer which does not prevent the garbage collection of the referenced object. Such pointers are commonly simply nulled (set to NULL) upon the referenced object""s death. The object containing the weak pointer is not immediately informed of the action and, indeed, many systems provide no form of notification to the application whatsoever. Since altering the internal data of an object without that object""s knowledge or consent breaks the object-oriented concept of encapsulation, weak pointers which do not inform their containing objects of their change in state are incompatible with fundamental object-oriented programming principles and concepts.
Moreover, there are other functional considerations reflecting upon use of memory management techniques. For example, sophisticated computer systems typically incorporate undo/redo functionality to assist the programmer/user by buffering unwanted actions. Undo/Redo systems are difficult to implement in current systems using weak/strong pointer technology.
One significant limitation of the current memory management systems is that the system designer has only very limited control over the destruction of objects. In other words, the systems prevent destruction of objects while any strong links exist. Utilization of strong and weak links provides partial solution to the problem by allowing destruction of items with weak links, however, a system designer lacks the tools to determine in advance when such memory management is occurring. Basically, the memory management system runs entirely in the background and is not available as an active programming device and, therefore, the current memory management approaches lack design flexibility.
Since the garbage collectors in languages having automatic memory management perform their tasks at unpredictable times, the collection times of the referenced objects are nondeterministic (and therefore difficult or impossible to use in many situations).
Thus, there is a need for a memory management system to facilitate computer system memory management design and implementation and address the various problems discussed herein.
The present invention is a Generic Memory Management System (referred to herein as GeMS) which defines relational schemes for memory pointers in object-based computer systems. GeMS includes a system of attributes associated with system references (pointers), thus creating a set of xe2x80x9csmart pointers.xe2x80x9d These attributes preferably are effected through a set of flags associated with the pointers, although generally any tagging methodology would be suitable. As discussed further below, in various embodiments include one or more of the attributes referred to herein as ownership, registered, alpha, omega, and ghost attributes.
In contrast with previous memory management schemes, the behavior of a GeMS smart pointer can be controlled by setting or clearing the flags contained within it. Thus, GeMS provides a computer system designer the tools (by means of the smart pointer flags) to determine when and how a system will perform garbage collection. A key feature of GeMS is that the GeMS explicitly controls when objects should xe2x80x98diexe2x80x99 and/or be deleted based on the relationships such objects have with other objects and the types (e.g., flags) of those relationships. As a result, for example, a computer program designer (i.e., programmer, developer or designer) using GeMS can now easily determine that a set of objects be linked to be deleted when threshold events occur.
Viewed from the perspective of a computer program developer/designer using GeMS; GeMS provides tools to allow a designer to efficiently determine how memory management will occur. Referring to FIGS. 1 and 5, it is noted that, for practical reasons, objects whose memory is to be managed by GeMS will be contained in a common base class, herein named GObject. Relations between GObjects are created using xe2x80x98smart pointersxe2x80x99 herein named SmartPtr. Every GObject maintains a tabulation of all SmartPtrs that reference it. In GeMS, how long a GObject xe2x80x98livesxe2x80x99 is based on the relationships it has with other GObjects, which relationships may be designed into the system by the designer in implementing the smart pointers. (In contrast, in typical memory management schemes in use today, an object will live as long as there are any references to it from anywhere in the application.)
GeMS incorporates the known concept of strong and weak relationships, but, in addition GeMS preferably can also determine when strong relationships should be broken based on additional adjectives that can be applied to the SmartPtrs by the application developer/designer. The preferred adjectives are named herein xe2x80x98alphaxe2x80x99 and xe2x80x98omegaxe2x80x99. Thus, all smart pointers are still either xe2x80x98strongxe2x80x99 or xe2x80x98weakxe2x80x99, but may optionally also be xe2x80x98alphaxe2x80x99 and/or xe2x80x98omegaxe2x80x99 pointers as well. (Alpha and omega functions link deletion of objects to other objects). Thus, in contrast to typical systems using weak and strong pointers, GeMS allows a designer to explicitly override existing strong relations and cause deletion of an object. Further, part of the preferred GeMS provides an express command for use by a designer/programmer to xe2x80x98killxe2x80x99 any GObject by a simple call to a procedure.
In one aspect, GeMS allows tabulations of smart pointers to be created, so that functions such as alpha and omega may be coordinated. Further, in a preferred aspect, the SmartPtrs referencing the xe2x80x98killedxe2x80x99 GObjects are properly updated and the repercussions of the object""s death will automatically ripple throughout the data model.
In one another aspect, GeMS provides an event handling system which enables the application to request important events from a data model when it changes. Thus, GeMS provides the capability to efficiently store a data model""s state so that the data model may be taken from one state to an earlier or later state (e.g., an undo/redo functionality).